A CDN is a geographically distributed network for delivering network content. Network content can include video, still images, text, sound, software, and numerous other types of electronic data. CDNs can include request routing servers and request routing agents positioned at various locations around the world. The request routing servers and agents work together to provide network content to clients.
Request routing servers and agents are typically used to increase the speed with which clients receive requested network content. In certain network configurations, when a client requests network content, a request routing server provides the Internet Protocol (IP) address of the nearest request routing agent that is able to serve the content. Using the IP address, the client requests the content from the nearby request routing agent.
CDNs may rely on network proximity measurements (network proximity is a measure of temporal proximity or latency) to route content requests to the request routing agents in closest proximity to the requesting clients. Network proximity is often actively measured. When proximity is actively measured, a request routing agent typically sends probe messages to a client agent. In response to receiving the probe messages, the client agent typically sends reply messages back to the request routing agent. Proximity is measured from the delay between when the request routing agent sends a probe message and when the request routing agent receives a reply to the probe message. Based on this message exchange, a request routing agent can estimate its proximity to the client agent. Request routing agents report these proximity estimates to the request routing servers, so that the request routing servers can determine which request routing agents are nearest to certain clients.
Request redirecting/routing servers, such as in the Global Request Manager (GRM) made by Network Appliance, Inc. in Sunnyvale, Calif., can redirect a client request based on proximity and policy. In order to redirect client requests correctly, client IP address and proximity information is stored in one or more tables in a request routing server and/or agent. This information is used by the server to determine the best surrogate (network cache) to provide content to a particular client. If the number of clients served by a CDN is large, the tables that maintain the client IP address and proximity information can become very large and thus unmanageable and may give rise to resource (memory) contention issues. Table size is particularly problematic in the request routing server if the system is configured for application-level (“level 7”) redirection, where the server maintains information for all clients that it serves.
Conventional systems work around this problem by reducing the number of client IP addresses stored by storing the prefix information and subnet mask. That approach helps constrain the size of the table, however, it suffers a drawback that reduces its effectiveness in re-directing clients accurately.
Assume, for example, that a conventional redirection system has two IP addresses: 202.54.1.18 and 202.54.1.30. The conventional system might treat all IP addresses with the same 28-bit prefix as a single entry. Thus, both of the above mentioned IP addresses end up being stored as a single entry in the redirection system table. Let us further assume that the proximity of the two IP addresses was different with respect to the surrogates due to subnetting. Because the conventional redirection system would store both IP addresses as a single prefix, it would be unable to redirect one of them correctly in the most optimal way, reducing the effectiveness of the request redirection system. A drawback conventional redirection systems suffer, therefore, is that they are unable to detect the subnetting information dynamically.